add a standalone dispose(), and make it work on every platform - #156

getStorage resolves a name's StorageFileInitOptions once and then ignores
them, so a store could not be reconfigured while the process lived —
changing an authentication validity duration meant restarting the app.
@luckyrat identified this in #138, following #75 and #137, and proposed
deleteAndDispose. This implements the standalone dispose() instead: the
use case is reconfiguring, and coupling it to delete made you destroy the
stored secret to change a duration. delete() first if you want both.

The method was already reachable natively and did not work.

Linux had no handler, so `dispose` fell through to
fl_method_not_implemented_response_new() and reached Dart as a
MissingPluginException. darwin replied `true` from a no-op that never
cleared `stores`, so the next init took its short circuit, discarded the
freshly passed options and replied `false` — success at every step, with
the file still on its original configuration. That silent one is why the
load-bearing test asserts through forceInit rather than trusting a bool.

Android reported the same operation by throwing NoSuchStorage on a
repeat, the only backend where disposing twice was an error. It now
returns whether there was anything to forget, which is the contract every
platform now shares.

win32 and web needed a fix that predates this API: `_initialized` was
keyed by the bare name while BiometricStorageFile carries the prefixed
one, so removing by the name dispose is handed would have matched nothing
and quietly returned false forever. Both now key on the prefixed form.

The stored content is deliberately untouched everywhere; this
reconfigures rather than erases, and a test pins that.

Verified: nine integration tests green on the iOS simulator, which
compiles the shared darwin sources and uses a sandboxed keychain rather
than the login one. Reintroducing the darwin no-op turned two of the
three new tests red — the reinit one and the idempotence one, while the
content-survives one correctly stayed green — and reverting restored
them. flutter analyze --fatal-infos and flutter test clean in both
packages. Linux and Windows are covered by CI.

Breaking for platform implementations only: `dispose` is a new member on
the BiometricStorage platform interface. No change for callers.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Two findings from review, a failure CI caught that the review did not,
and a footgun found while checking the fix.

A disposed BiometricStorageFile documented that it must not be used
again, and nothing enforced it — so the consequence of ignoring the doc
differed by platform. Android and darwin resolve read, write and delete
against their registry and fail once the entry is gone, while Linux,
Windows and web answer from the name alone and carry on working. That is
a mistake you make on one platform and discover on another. The guard now
sits in Dart, so every backend answers alike: read, write and delete
throw a StateError, and dispose deliberately does not, because disposing
twice has to stay legal.

The flag is set before the call is awaited, not after. That brick a
handle whose native dispose then fails, which is worth it: Dart always
sends `name`, so the argument-error paths are dead, while the race it
closes is reachable by any caller who does not await dispose() and would
otherwise slip a read into the window — succeeding on three platforms and
failing on two, which is the divergence this guard exists to remove.
Recovering costs one getStorage.

dispose is scoped to the name, not to the handle: every handle is a view
onto one name-keyed initialization, so a spent handle still forgets an
initialization made after it. Documented and tested, because the
tempting optimization — short-circuiting a repeat dispose on the local
flag rather than asking the platform — would quietly make it
handle-scoped and return a wrong answer.

The `null reply is reported as nothing-to-forget` test was vacuous and is
gone. No deployable combination replies null — the handlers that predate
this either answer true, or throw, or are missing entirely, which
surfaces as MissingPluginException — and the `?? false` it claimed to
guard is enforced by the compiler anyway, since invokeMethod<bool> is
typed Future<bool?>. The coercion stays, with a comment saying what it is
actually for.

The remaining dispose unit tests are skipped on a Windows host. They
drive MethodChannelBiometricStorage, whose dispose asks
_promptInfoForCurrentPlatform for a prompt it has no windows case for, so
they failed there with "Unsupported Platform windows". Not reachable by
users — the registrant installs Win32BiometricStoragePlugin — and
biometric_storage_win32_test.dart covers dispose on that host.

Adding the guard invalidated two things written alongside it: a win32
teardown that deleted through the handle it had just disposed, and the
example's claim that read and write keep working afterwards. Both fixed.

Verified by execution on all five backends. Eleven integration tests
green on the Android emulator, the iOS simulator and macOS; Linux runs
the same suite against real libsecret in CI, and Windows runs the win32
unit suite, which reaches the same dispose paths by a different route.
Reintroducing the Android NoSuchStorage throw turned two red — the
idempotence test and the guard test's closing assertion — and reverting
restored them; the darwin no-op did the same earlier. Both mutation runs
predate the last two tests, so they show those fixes are caught, not that
every test in the suite is.

macOS had never run this suite before, having been signing-blocked; a
provisioning profile now exists. It writes to the real login keychain, so
the run was bracketed by a keychain baseline — zero integration_ entries
before and after, which is what says teardown cleans up rather than that
the tests passed. No prompt appeared, which is what authenticationRequired
false is for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>